Skip to content

Add i18n fallback #815

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 28, 2019
Merged

Add i18n fallback #815

merged 1 commit into from
May 28, 2019

Conversation

renyuneyun
Copy link
Contributor

@renyuneyun renyuneyun commented May 26, 2019

A better handler for i18n fallback, using fluent-locale.

This shall separate the logic for fallback, and make more advanced fallback implemented easier.

@renyuneyun
Copy link
Contributor Author

One personal expectation is to unify most (if not all) Chinese resources, taken the advantage of an automatic converter OpenCC (rust binding).

OpenCC supports the convert between Simplified and Traditional characters as well as regional term (Mainland, Hong Kong, Taiwan, etc). It generally works well (it's the best one I ever see).
But there are a few cases it may not work well (due to the nature of this task (I can explain in more details if needed)). Localized resources can then be added (with higher priority) when automatic convert doesn't work well (after people reported).

@Manishearth
Copy link
Member

Manishearth commented May 26, 2019

Can you implement this on top of the i18n branch? A lot has changed there. I plan to merge that into master at some point, but for now we're doing all the internationalization work there so that we don't accidentally break the main website.

Also, we'll have to have a hardcoded list of supported languages (for the dropdown) anyway, so we should probably structure this around that.

@renyuneyun renyuneyun changed the base branch from master to i18n May 26, 2019 20:43
@renyuneyun
Copy link
Contributor Author

@Manishearth Ok, no problem.
I'll rebase it now, and then try to use reference.

@renyuneyun
Copy link
Contributor Author

@Manishearth I see in the code (both master and i18n branch) that the RESOURCES and BUNDLES are created using the older way (and the lifetime for a lot of things is explicitly specified as always 'static). Is this due to the bug your previously mentioned?

Would that be a good idea or a bad idea to minimize that piece of lifetime in struct's and function's definitions?

@Manishearth
Copy link
Member

We don't want to minimize it. It's a static object. Being 'static is deliberate, it's much easier to work with.

We may want to make it possible to reload files while running, but that's a significant amount of work, and it has little benefit given our current deployment model.

Copy link
Member

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. I'll test it out soon.

@Manishearth
Copy link
Member

Thanks!

@Manishearth
Copy link
Member

This needs to be tweaked to deal with the governance stuff correctly, though.

@Manishearth
Copy link
Member

Oh, I realized that this approach won't work for the governance at all: We shouldn't use the fallback chain for defaulting to English, because our English default works differently in different places.

Furthermore, we should definitely not be recomputing this each time. I've got a plan.

@Manishearth
Copy link
Member

Also, we shouldn't be using lifetimes here, again 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants